A traditional way of designing and implementing various data processing devices has been based on a centralized application engine. That is, a data processing device typically comprises a central processing unit (CPU), which may consist of one or more processors, and other parts and subunits of the computing system. The CPU then controls the operation of the whole computing system by delivering operation command to the subunits and by processing and transferring data to and from the subunits.
In general, software programs may consist of instruction sets executable by the CPU, which are arranged to receive input from the other units of the system for calculating an output of that instruction set. Further software blocks of instruction sets are transferred into a software modules which, in turn can be integrated together to form more complex software programs.
These sophisticated software programs may receive input in various forms for example as in raw data from mass storage hardware, as an user input from variety of user input devices, electronic information from different kinds of sensor devices, etc. In some instances, programs may be configured to produce data usable by other software applications. In these instances the chain of applications is not restricted, and various combinations of input/output relations can be produced. However, in these kind of setups problems may be presented when information is conveyed from one program to another. If the relationship is known before the software program code is created, then it is relatively easy to build up the system so that it uses one program's output as an input for another program. This kind of approach leads to rigid application relation architecture, where the functions of the software code and transactions between software entities are smooth, but the flexibility is lost and changes in functionality and architecture require each time remarkable revisions and effort.
However, more flexible modular software architectures for sharing information amongst programs have evolved recently. The modularity of a software architecture is used for breaking bindings between traditional software architecture blocks. Software modules can be removed, revised or modified without having to suspend the overall operation of the device. Software modules may contribute information to a shared memory space. Some other modules may be specialized to provide communication services. Altering program elements constructed according to this architecture may not affect program elements that are communicating with other program elements, nor jeopardize information stored in the system as long as shared memory space is available for other program elements in the system.
Software applications produced with modular elements can be used for example in situations where software applications are producing connectivity capabilities between two peer instances. The upper layer application using connectivity may require only reliable transport service for its data, while not setting expectations for the technique of conveying the data. In this situation modularity enables the change of used transport technology beneath if predefined event triggers the initiation of the change. This may mean for example switching the transport layer mechanism from a Universal Mobile Telecommunications System (UMTS) network to a Wireless Local Area Network (WLAN) connection if device comes to a range of a WLAN hotspot.
Current modular software architecture is restricted with very narrow application centric approach, where all architecture layers are designed for accomplishing specific service functionality from the top of the user inputs all way down to the physical layer implementation. Even though the transport mechanism can be changed currently beneath the application level, the procedure is static and tied to predefined resources and application instances initially configured to the system.
Hence there is a need for enhancing modularity and adaptivity of the software architecture in such a way that available resources for the software unit and communications between architectural modules can vary in time and the software program code will interact with its surroundings and resources in dynamical and adaptive way.